A database generally employs a master/slave architecture mode, which includes a master database server and a slave database server. The master database server is used for providing external services, and the slave database server serves as a backup for the master database server. When the master database server goes down, the slave database server can continue to provide services originally provided by the master database server, thereby improving the usability of the database.
When using a database, a user may perform an operation on data in the database, which may lead to changes in the data. Data changes may include operations that may change the data, such as a deletion, an addition, and replacement of the data. In order to record these data changes, the master database server may generate a corresponding data log for a data change, to record a data object that is changed and changed content of this data change. In order to continue to provide users with services that are originally provided by the master database server when the master database server goes down, the slave database server needs to receive data logs recorded by the master database server from the master database server, and conduct log replay using these data logs, to implement synchronization between database data in the slave database server and database data in the master database server.
When a relatively large number of user connections exist in the master database server, the master database server may generate a large amount of data logs. If a log replay speed of the slave database server is excessively low, the data logs received by the slave database server cannot be replayed in time, causing the data logs to pile up at the slave database server. At this point, if the master database server goes down, the slave database server cannot replace the master database server immediately. Only after the slave database server finishes the log replay of the piled data logs can the slave database server start to provide services to users, thus affecting user experience.
In order to finish log replay of the data logs received from the master database server in time, the slave database server needs to carry out log replay on the data logs concurrently, to improve the efficiency of log replay. In order to implement concurrent log replay on the data logs, the slave database server needs to fragment the received data logs to obtain multiple fragments. The slave database server may simultaneously replay multiple fragments, so that a concurrent log replay function is implemented on the slave database server.
Currently, how to efficiently fragment a log is an urgent problem to be solved.